In dieser Aufgabe kümmern wir uns um asynchrone Ereignisse, Unterbrechungen durch externe Geräte,

in unserem Fall primär durch die Tastatur, aber optional auch die Maus.

Wie wir in der Musterlösung sehen, unterbrechen die Tastaturereignisse abwechselnd alle Kerne,

und Kämper an den unterschiedlichen Farben.

Dieses Verhalten konfigurieren wir mittels den IOAPIC.

Damit tauchen nun auch Synchronisationsprobleme auf.

Diese kritischen Abschnitte können wir mit Ticket oder Spinlocks schützen.

Optional gibt es die Möglichkeit einen GDB-Stub einzubauen, welcher zusammen mit der seriellen

Schnittstelle ein Remote-Debugging erlaubt.

Dazu müssen die Gerätetreiber wie Keyboard implementiert werden, welche sich dann bei

der Plugbox für gewisse Interrupts registrieren.

Die Unterbrechungsbehandlung Interrupt-Händler soll dann diese Plugbox nutzen, um das Gerät

objekt zum jeweiligen Interruptvektor zu bekommen.

Daneben muss noch der PS2-Controller an den Interruptbetrieb angepasst werden und die

IOAPIC-Konfiguration implementiert werden.

Und wie konfiguriere ich diesen Advanced Programmable Interrupt Controller?

Nun dazu muss ich wissen, wo, an welchen der 24 Eingänge, ein Gerät am IOAPIC angeschlossen

ist.

Was aber je nach Rechner unterschiedlich sein kann.

Abhilfe schafft die Systemkonfiguration ACPI.

Diese besteht aus vielen Tabellen, in welcher auch die gesuchten Informationen stehen.

Diese Angaben über die Verdrahtung der angeschlossenen Geräte aus den ACPI-Tabellen werden während

der Initialisierung von unserer APIC-Klasse eingelesen und über die Funktion Get IOAPIC-Slot

zur Verfügung gestellt.

Ebenfalls kommt da auch die noch zusätzende ID des IOAPIC her.

Nun müssen wir auch noch einstellen, wer bei Interrupts benachrichtigt werden soll.

Im Gegensatz zu O-Stubs ist das bei MP-Stubs nicht so einfach.

Wir wollen zu Übungszwecken eine Gleichverteilung auf alle Kerne.

Dazu setzen wir die Priorität eines jeden LAPIC bei der Initialisierung auf Null, das

ist bereits so implementiert, und wählen im IOAPIC die niedrigste Priorität als Zustellmodus.

Außerdem verwenden wir die logische Adressierung für die Ziel-CPUs.

Damit können mittels Bitmaske alle CPUs angegeben werden.

Das sieht dann im Redirection-Table Eintrag so aus.

Gleich oben sieht man die Bitmasken für die Ziel-CPUs.

Das kann man auch dynamisch machen, aber man solle keinesfalls nicht existente CPUs adressieren.

Das mag zumindest die Testartwelle überhaupt nicht.

Dazu muss natürlich auch Delivery und Destination Mode entsprechend gesetzt sein.

Ob der Interrupt aktiv ist und falls ja, ob er flanken oder pegelgesteuert ist, hängt

vom jeweiligen Slot bzw.

Gerät ab.

Die Tastatur ist zum Beispiel pegelgesteuert.

Die Felder Remote Interrupt Request Register und Delivery Status können wir nicht ändern.

Und für den Interrupt Vektor sollte man sich systemweit einig sein, welches Gerät was

verwendet.

Entsprechend gibt es unter Maschinen im Header CPU Interrupt ein Inam dafür.

Wenn ihr das nun in KVM testet, kann es sein, dass die Tastatur Interrupts immer auf der

gleichen CPU ankommen.

Das könnte auch am Vektor Hashing liegen.

Die Interrupt Nummer wird bei neueren KVM Versionen modulo Anzahl CPUs genommen und zugeteilt.

Das ist zwar eine gute Optimierung bezüglich Cache-Lokalität und so weiter, aber wir wollen